Who Do You Trust? OAuth Client Application Trends

Introduction

Federated identity systems, such as Google Identity, bring security and convenience in the form of SSO for Internet or cloud applications. It is common to be prompted for authentication in order to grant various levels of access or permissions for applications ranging from Google Drive, Google Cloud SDK, Google Chrome plugins, Slack, Adobe, Dropbox, or Atlassian to numerous third-party apps.

This is all part of OAuth client application authentication, where a user can securely enter their credentials (which are not shared with the requesting application) and approve the privileges or access (scopes) requested by the application.

However, this set of trust relationships can cause security problems, such as data exposure/loss or data modification, if malicious applications or overly broad permissions are granted.

In this blog, we take a closer look at real-world user activity showing which applications are being trusted and which scopes (permissions) are being granted using Google Identity given its widespread adoption. We’ll analyze anonymized data from Netskope customers that includes 439 organizations, over 500,000 users, and over 60,000 applications. We will look specifically at:

• Modify/write permissions most requested by applications
• Which apps may pose more risk to users
• Overly broad scopes that increase risk

It’s a wonderful application world

What kind of applications are being trusted by corporate Google identities, and therefore, likely being accessed from work computers/devices? 

Here are the top-12 applications that are trusted by at least 5% of the users:

These 12 applications alone are trusted by 497,109 of the users (97% of the total users). Some of these might be official or de facto corporate standards such as Google Chrome (log into Chrome with your Google Identity), Zoom, Slack, Atlassian, or Adobe. Other applications such as iOS Account Manager or Android device or macOS, represent trust to native applications running on those operating systems (e.g. Mail, Chrome, Google Drive).

We also see specialized applications and personal applications:

Scope creep

What kind of permissions (OAuth scopes) are being approved by all these applications? 

Here are the top 10 scopes (ranked by # of users) that grant “manage” (modify) permissions:

In this list, the “view and manage spreadsheets in Google Drive” scope is requested by the most applications: 11,124 (18.3% of all apps). Some questions that come to mind:

• Do all of the apps requesting these scopes require “manage” as well as “view” permissions?
• Does the “View and manage the files in your Google Drive” scope really require access to all files or could/should it be restricted to “View and manage Google Drive files and folders that you have opened or created with this app?”

From a security viewpoint, it would be ideal if application access was restricted to only the data they generate themselves. For these types of cloud apps, their scopes would have a narrow set of privileges such as:

• View and manage Google Drive files and folders that you have opened or created with this app
• View and manage forms that this application has been installed in
• View and manage your data for this application

However, there are valid example types that require broader privileges such as general file sharing or search applications that might need access to your whole Google Drive, or a photo-editing application that needs access to all image/video file types regardless of origin.

It would be natural to focus on applications that request potentially broad scopes and that have higher risk due to the high number of users using those applications. This helps us identify risky applications. Many of these applications have high user counts because they are popular or are corporate standards.

However, we shouldn’t ignore applications with broad scopes that are only used by a few users. These applications may not be popular and may not be developed by well known vendors. However, if they have risk, it indicates that you may have users engaging in risky behavior. This helps us identify risky users.

In general, we can look at scope-based risk along two dimensions and locate applications within the matrix:

The scope dimension reflects the breadth of permissions allowed by the scope ranging from narrow to broad. The # of users dimension identifies the number of users that use a particular scope. High numbers of users using a particular scope is risky due to the wide usage, but often this is because an application has become a corporate or de facto standard by a well-known company, so the risk factor is more related to the application. Whereas, less-known applications used by few users tend to reflect individual choices and decisions to use applications that are not approved,which reflects more on risky user behavior.

Through this framework, we can start to identify the biggest risk areas to focus on for reducing risk, as we’ll attempt in the following sections.

Overly permissive scopes

Overly permissive scopes include unneeded manage/modify/write permissions or just extra permissions that an application may not require, for example:

• A scope such as “View and manage the files in your Google Drive” raises the question of whether write access is required or would “View the files in your Google Drive” or “View and manage Google Drive files and folders that you have opened or created with this app” suffice?
• Extra permissions or scopes being requested that are unexpected for that application could also raise questions (e.g. a spreadsheet application requesting access to contacts).

To gain a sense of higher impact applications, here are the top 20 applications in terms of users that request the “View and manage your mail” scope:

As expected, most of the apps relate to email, but with less obvious applications, it’s worth reviewing, for example:

• Adobe Acrobat is a well-known PDF read/write application, but why does it need read and write access to email? It turns out there is feature that could readily explain this scope request: Gmail integration to send PDFs by email. However, this shows how a convenience feature (being able to easily email PDFs), increases exposure because the application, Acrobat, has full access to your email. This could be acceptable but should be an explicit decision.

As a different example, in our dataset, there is one application trusted by one user, appears only in one organization. It appears to be an internal tool, its title relates to GSuite Security alerts and its list of scopes are:

Manage data access permissions for users on your domain
Manage delegated admin roles for your domain
Manage messages in groups on your domain
Manage the list of sites and domains you control
Manage your Google Classroom class rosters
Manage your Google Classroom classes
Manage your calendars
Manage your contacts
View and manage Google Apps licenses for your domain
View and manage customer related information
View and manage data transfers between users in your organization
View and manage organization units on your domain
View and manage the provisioning of calendar resources on your domain
View and manage the provisioning of domains for your customers
View and manage the provisioning of groups on your domain
View and manage the provisioning of user schemas on your domain
View and manage the provisioning of users on your domain
View and manage the settings of a Google Apps Group
View and manage your Chrome OS devices' metadata
View and manage your mobile devices' metadata
View audit reports of Google Apps for your domain
View the email addresses of people in your classes
View the profile photos of people in your classes
View usage reports of Google Apps for your domain
View your basic profile info
View your data in Google Cloud Storage
View your email address

This scope list approaches administrator control over the entire Google domain, so either it is misnamed or it’s clearly over-privileged. Regardless of the situation, this application design should be reviewed to determine whether isolation of privileges can be done so that a compromise of one user’s credentials or oauth tokens does not immediately expose the whole domain. Certainly tight controls like MFA help mitigate the risk, but hijacking of OAuth tokens bypasses MFA, so practicing minimal privileges (in this case, minimal scopes) is always a good idea. This is an example where the risk source is a combination of both application design and user decisions.

Sensitive data scopes and all files/data of type X

Email, spreadsheets, and Google Drive have higher chances of containing confidential information vs. other data such as your Contacts. Some scopes in this category are:

• View your emails messages and settings
• View the files in your Google Drive
• View and manage your spreadsheets in Google Drive
• View and manage your data in Google BigQuery

A specific case of sensitive data scopes includes scopes that allow access to all data/files of a certain type. Presumably the application uses this data/file type, which is also used by other applications, for example a spreadsheet application needs to read/write any spreadsheet files, not just the spreadsheets it created. Here are some common examples:

• View the photos, videos, and albums in your Google Photos
• View and manage your spreadsheets in Google Drive
• View and manage your forms in Google Drive

Here are the top applications by user that have requested “View and manage your spreadsheets in Google Drive”:

In this case, when looking at broader scopes over more data, we would ask ourselves several questions:

• Does the application require read/write access to everything in Google Drive? For “file-system management” applications, the answer could be “yes.” 
• However, for an application that does “searching” of Google Drive, we might ask whether a “search-like” application requires write access. 
• For any other applications that don’t seem to have features that require access to all of your Google Drive, we might need to investigate further determine if scopes should be more restrictive to data generated only by the application.

As a different example, the CamScanner application is only used by 219 users (.04% of 509.079) and requests “View and manage the files in your Google Drive,” one of the broadest data scopes for regular users. CamScanner was found by Kaspersky in August 2019 to contain malware and was banned by the Indian government over security concerns in June 2020. This reinforces the need to manage application trust and usage, and that risky behavior for a small number of users should also be analyzed, not just applications affecting the largest number of users.

Controls

To operationalize the use of application trust and scope information, we can take a structured approach with multiple defensive measures.

Application policies

One should start by creating policies that define which applications are allowed to be used/trusted by users in your organization. During testing/evaluation of new applications, the definitive application name and client id should be recorded (from the Google Workspace Admin Console > Reports > Audit log > Token report)—this information is crucial for accurate detection of these applications.

Prevention

Once policies are defined, you can enforce your policies upfront by preventing the trust of applications not allowed. The Google Workspace Admin Console allows various API controls to block all third-party API access and whether to trust internal, domain-owned applications:

Detection/Auditing

Ongoing auditing and detection of unauthorized applications can be done in several ways:

• Audits can be done using the Google Workspace Admin Console > Reports > Audit log > Token report. This information can be programmatically retrieved via API.
• Real-time Detection can be done by inline controls that can detect not only applications being accessed but also instances in order to distinguish access to personal vs corporate instances. Various proxies and CASBs can help here.

Mitigation

Should unapproved applications be trusted and detected after the fact, then revocation of the application can be done via Google Workspace Admin Console or API. In the Console, Users > users > Security > Connected Applications > Edit will allow disconnection (revocation) of any connected application for that user.

Conclusion

User trust of OAuth client applications that request broad scopes and privileges from the user, can increase risk of exposure of user data (privacy issues or data exfiltration by malicious applications). Understanding the web of applications trusted by users is difficult and there are likely unauthorized applications as well as over-privileged access in any organization. All of this increases the risk of exposure of malicious applications with overly broad data access.

In order to manage this risk better, it’s recommended to:

• Create clear policies on approved/unapproved applications
• Prevent unauthorized applications from being trusted by utilizing Google Workspace Admin security controls to control approvals.
• Detect unauthorized applications in real-time through the use of proxies/CASBs such as the Netskope Cloud Security Platform.
• Mitigate unauthorized apps by immediately revoking them in the Console or via API

Dataset and Methodology

Time Period: Google Workspace oauth audit logs were analyzed from April 18, 2021. 

Source: The analysis presented in this blog post is based on anonymized usage data collected by the Netskope Security Cloud platform relating to a subset of Netskope customers with prior authorization.

Scope: This dataset was drawn from 439 Google Workspace organizations, which included 509,079 users, and 60,875 unique applications.